E.164 number mapping (ENUM) refers to the translation of E.164-formatted telephone numbers into uniform resource indicators (URIs) resolvable by a domain name system (DNS) server into Internet protocol (IP) addresses. ENUM has been extensively deployed worldwide in order to provide integration between IP networks, such as the Internet, and the public switched telephone network (PSTN). In one proposal, as described in RFC 2916, the telephone number format used in ENUM translation is the E.164 number format. According to ITU-T standards, an E.164 telephone number may include up to 15 digits and include a leading + symbol indicating that the number is globally unique. For example, a valid E.164 telephone number may include +420-123456789. ENUM translation of an E.164 number into an IP network identifier may include formulating an ENUM query including the E.164 number and querying an ENUM database containing one or more naming authority pointer (NAPTR) records that associate individual E.164 numbers with one or more IP network identifiers. A NAPTR record is a type of DNS record that supports regular-expression-based rewriting, where each network identifier within the NAPTR record may differentiated based on a variety of parameters. Thus, a NAPTR record may contain multiple URIs associated with a single telephone number, where each URI may be differentiated based on an order, a preference, and a service. For example, the E.164 telephone number +420-123456789 may be associated with SIP URI smith@domain.org, H.323 URI smith@domain.org, and email URI smith@domain.org within a NAPTR record located in an ENUM database.
Upon receiving an ENUM query, the ENUM database may locate and return the NAPTR record associated with the telephone number included in the query. Additional translations may be required in order to select a particular network identifier from within the provided NAPTR record to first attempt to connect to. Typically, ENUM queries are processed by an ENUM database located near the query originator in order to reduce the response time for an ENUM response. Therefore, conventionally, multiple identically provisioned ENUM databases may be distributed throughout a particular geographic area such that each database is capable of responding to an ENUM query associated with any subscriber within the network.
One problem with some conventional ENUM systems is that all ENUM databases contain a complete set of ENUM data associated with all subscribers in the network. Yet as more subscribers and services are added to existing networks, including text and multimedia messaging services, voice over IP (VoIP), and other Internet multimedia subsystem (IMS) services, the volume of ENUM data stored in each of these ENUM databases increases correspondingly. As the volume of ENUM data increases, it becomes increasingly difficult to maintain all ENUM data within a single ENUM database.
In ENUM database systems where multiple identically provisioned databases serve a network, routing is simple because queries can be sent to any of the databases for translations. For example, queries may be load shared among identically provisioned ENUM databases.
In some instances, ENUM databases that serve a network may not be identically provisioned. For example, when an operator's existing ENUM database becomes maximally utilized, the operator may desire to bring a new ENUM database into service and move a portion of the subscriber data from the old ENUM database to the new ENUM database. As a result of moving the portion of the subscriber data to the new ENUM database, the new and old ENUM databases do not contain identical sets of subscribers ENUM data. Consequently, switches that formulate ENUM queries must be provisioned with location information that identifies the ENUM database that holds a particular subscriber's data. Requiring switches to be reprovisioned with ENUM database location information for each subscriber is labor intensive, especially in networks with a large number of existing switches. Such reprovisioning can be required any time the service provider desires to move subscriber ENUM data among ENUM databases. As a result, there exists a need for improved methods, systems, and computer program products for routing and processing ENUM queries.